1. Field of the Invention
The present invention relates to updating a data record in a data store. In particular it relates to synchronized updates to a data record by multiple updaters.
2. Technical Background
Synchronization of updates to data in a data store where there are multiple possible updaters of such data is essential to ensure updates to data are not lost or overwritten. For example, data records including data fields can be stored in a database accessible to multiple software applications for update. FIG. 1 illustrates a locking technique for synchronizing updates to data records in a data store 102. The data store includes a record having two fields with initial values of “A” and “B”. A first record modifier 104 and second record modifier 106 are operable to read the record from the data store 102. Initially, the first record modifier 104 applies 110 a synchronization lock to the record in the data store 102 and reads 110 a copy of the record into a memory local to first record modifier 104. The synchronization lock can be an indicator or flag which is useful to prevent other modifiers (such as second record modifier 106) from accessing the record in the data store 102 whilst the lock exists for first record modifier 104. In this way, the first record modifier 104 is able to work with the record from the data store 102 without concerns that other record modifiers are manipulating the record in contemporaneously.
As is illustrated in FIG. 1, second record modifier 106 subsequently attempts 120 to lock the record in the data store 102 unsuccessfully. This is because the record is already locked by the first record modifier 104 and so the second record modifier 106 is required to wait 122 for the lock to be released by the first record modifier 104. The first record modifier 104 modifies 112 the copy of the record in memory by changing a value of a field of the record from “B” to “C”. First record modifier 104 subsequently updates 114 the fields of the record in the data store 102 to reflect the modifications made to the copy of the record in local memory. Once the required update by first record modifier 104 is complete, the first record modifier 104 releases 114 the lock it has over the record in the data store 102. At this point, the second record modifier 106 is able to lock and read 124 the record from the data store 102 into a memory local to the second record modifier 106. The second record modifier 106 is able to modify 126 a field of the record in local memory and update 128 fields of the record in the data store 102 to reflect the modifications made to the copy of the record in local memory. The second record modifier 106 finally releases the lock 128.
The approach illustrated in FIG. 1 is effective to ensure synchronization of updates to a record in a data store by means of a locking mechanism which excludes modifiers from accessing a data record where those modifiers are not in possession of a lock on the record. However, this approach has substantial drawbacks. In particular, the approach of FIG. 1 prevents all simultaneous access to the data record in the data store 102, requiring modifiers to wait 122 until a lock is released. This is particularly disadvantageous where a modifier requires a relatively lengthy lock on a data record, for example where user interaction is required to undertake the modifications to data fields. Such delays can have an enormous impact on other processing activities awaiting release of the lock.
An alternative approach which addresses some of these concerns is known as the “optimistic offline lock” and is described in some detail in the book “Patterns of Enterprise Application Architecture” (Martin Fowler, 2002). Optimistic offline lock is a design pattern for addressing the problem of controlling updates to a data record in a data store in such a way that changes made by one modifier do not coincide with changes made by another modifier without requiring the locking of data records. A modifier that retrieves a data record from a data store does not lock the data record but instead checks, when it comes to updating the data record in the data store, that the fields in the data store are still as they were when they were first read. Only if the data in the data store is unchanged can an update proceed.
FIG. 2 illustrates an optimistic offline locking technique for synchronizing updates to data records in a data store 202. Many of the features of FIG. 2 are identical to those described with respect to FIG. 1 and these shall not be repeated here. Initially, a first modifier 204 reads 210 a data record from a data store 202 into a memory local to the first modifier 204, the data record having two fields with values “A” and “B”. These values are stored 212 by the first modifier 204 as initial values of the data record—being the values of the data record at the time the data record was read by the first modifier 204. Subsequently, a second modifier 206 also reads 220 the data record from the data store 202 into a local memory having the same two fields with values “A” and “B”. These values are also stored 222 by the second modifier 206 as initial values of the data record—being the values of the data record at the time the data record was read by the second modifier 206. Meanwhile, the first modifier 204 undertakes modifications 214 to a field of the data record in local memory, changing a field value from “8” to “C”. The second modifier 206 also undertakes modifications 224 to a field of the data record in memory, changing a field value from “A” to “D”.
The first modifier 204 commences an update operation to update the field modified by the first modifier 204 in the data store. The update operation involves the first modifier 204 determining 216 whether the field values of the record in the data store have changed from the initial field values recorded at step 212. Since the record on the data store is unchanged, the first record modifier 204 updates 218 a field in the record in the data store 202 to reflect the modifications made to the copy of the record in memory. The record in the data store now has updated field values of “A” and “C”. Subsequently, the second modifier 206 commences an update operation to update the field modified by the second modifier 206 in the data store. The second modifier 206 determines 226 whether the field values of the record in the data store have changed from the initial field values recorded at step 222. The initial field values recorded by the second record modifier 206 at step 222 were “A” and “B” and the record in the data store now has different field values of “A” and “C”. These different field values result from a previous update performed by the first modifier 204. Thus, the second modifier 206 determines 228 that there have been parallel updates to the record in the data store and so the update of the second modifier 206 is not able to complete. The second modifier 206 may be required to retry the entire process of reading, modifying and updating until successful.
The approach of FIG. 2 is effective at ensuring synchronized updates to data records in a data store. However, the approach has the disadvantage that updates to disparate fields in a data record by multiple modifiers are prevented even where there is no overlap of updates to the data in the data store. This is clear from the particular example illustrated in FIG. 2 where the second modifier 206 is prevented from applying an update to the data record in the data store 202 even though the first modifier 204 and the second modifier 206 updated disparate fields in the data record.
It would therefore be advantageous to provide for synchronized updates to a data record in a data store by multiple modifiers where there is disparity in the fields of data being updated and inspected by each modifier.